Versioning of stored information is a well-known issue in information storage and retrieval industry. Information storage and version management can be achieved in several ways.                Storing new versions in completeness is an easy and fast option but has storage ramifications.        Storing either the first or the latest version and storing the deltas, which can be used to create other versions. This approach is storage efficient but results in slowing down of a response to a query requiring versions that need to be calculated using the deltas.        
Besides the above-mentioned limitations of both schemes, one major issue with most versioning solutions is that a versioning chain reaction takes place when an object is versioned. Specifically, versioning of one object normally leads to versioning of a number of other objects that may be in some way related to the object being versioned. Such additional versions are exact clones of the old information and yet need to be handled as new versions.
For example creating a new version of a Department (e.g. in a corporation that is being modeled) according to such a scheme would require creating copies of all Employees within that department.
Storing of multiple versions of a particular object is described in U.S. Pat. No. 6,460,052 granted to Thomas et al. on Oct. 1, 2002 and entitled “Method and system for performing fine grain versioning”. U.S. Pat. No. 6,460,052 is incorporated by reference herein in its entirety. Specifically, U.S. Pat. No. 6,460,052 states (see Abstract) that a table includes one or more additional columns for storing version information on each object being stored in the table. In response to a request from a user to retrieve a particular object, a version of the particular object to present to the user is automatically determined based on a workspace associated with the user. The version of the particular object is presented to the user without exposing to the user values from the one or more columns in which version information is stored.
According to U.S. Pat. No. 6,460,052 (see column 5, lines 18–26), in one embodiment, each user has a “working context” that defines the set of objects that can be seen by the user. The user accesses the user's working context through a “version resolved view”. The working context of a user defines a set of “configurations” that are associated with the user's workspace. A configuration is a collection of object versions, where each object version in the configuration is for a different object.
U.S. Pat. No. 6,460,052 further states (see column 11, lines 40–50) that when an object is inserted, deleted or updated within a version-resolved view, one or more triggers evaluate access control to determine whether or not the operation can be performed. If the operation is allowed, the triggers of U.S. Pat. No. 6,460,052 construct subordinate SQL that is necessary to insert, delete or update the object within the table, and create the configuration members so that the object can be seen in a subsequent select operation back through the version-resolved view, inserts the object into the current working folder so that it will be seen when navigating the folder, and does the background evaluation of the constraints for generating the corresponding version history information. U.S. Pat. No. 6,460,052 also describes (in column 14, lines 25–45) a set of utilities that automate the process of making software changes.
U.S. Pat. No. 6,460,052, also states (see column 6, lines 14–22) that by providing each user a current working context in which only one version of each object is visible, the database tools can use the repository without having to be aware of the additional complexity that is introduced by version control. In this manner, all work that is performed to track and maintain version information is transparent to the tool. Thus, existing tools that were not designed to support versioning can obtain the benefit of version control without having to be modified. Specifically, the mechanism of U.S. Pat. No. 6,460,052 avoids certain cloning chain reactions because the references to objects remain valid regardless of versions, and the version resolved view projects the appropriate version (e.g. version 2 as opposed to version 1).
U.S. Pat. No. 6,460,052 also describes (see column 7, lines 16–25) a table (called “configuration members”) that provides a mapping of configurations to the specific object versions that are associated with the configurations. As previously described, a configuration is a collection of objects that are related in some way that is significant to the user. For example, a configuration may represent all the objects that make up a given component or release. Using the configuration members table, a version control mechanism identifies the specific objects and the specific object versions that make up a particular configuration.
Moreover, the version control mechanism (see column 5, lines 12–21) maintains a user workspace for each user. The user workspace of a user includes an object version of each of the objects that have been “checked-out” by the user. The version control mechanism protects the object versions in a user's workspace from changes by other developers. In one example, each user has a “working context” that defines the set of objects that can be seen by the user. The user accesses the user's working context through a “version resolved view”.
The working context table (see column 7, lines 49–59) defines a list of configuration objects that are currently mapped to a user's workspace. In one example, each user is provided with a private working context. The working space provides a view of those data items that the user is currently working on (“version resolved view”) and protects those data items from being changed by others. A working context may include both structured and non-structured data. Thus, a private working context may include not only file based information but also information that is stored within a table.